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SYSTEM AND METHOD FOR BROADBAND MULTI-USER 
COMMUNICATION SESSIONS 



CROSS-REFERENCE TO RELATED APPLICATION 

This patent application claims the benefit of Provisional Patent Application, 
Serial No. 60/203,761, entitled Distributed Broadband Access Network Architecture 
System and Method, filed on May 12, 2000. This patent application is related to co- 
pending patent application, Serial No. , Attorney Docket No. 

13559RN, entitled System and Method for Joining a Broadband Multi-User 
Communication Session, filed on December 21, 2000. 

FIELD OF THE INVENTION 

This invention relates to telecommunications equipment and networks, and 
more particularly, to a system and method for broadband multi-user communication 
sessions such as e-gaming. 
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BACKGROUND OF THE INVENTION 

Public groupware and multi-user gaming are popular new Internet 
applications. However, their functionality and performance are limited and 
unappealing because the users find the current environment to have jerky interaction, 
infrequent screen updates, unacceptably slow speed, and lack of realism. These 
problems are primarily due to the lack of bandwidth over the Internet. Currently, 
when two or more users participate in the same multi-user session, each user has to be 
logged in at a central computer server. Therefore, the capacity of the central 
computer server becomes a constraint on the number of users that can participate 
simultaneously. The central server becomes a bottleneck and the architecture is not 
easily scalable to accommodate more users. There is also a lack of quality of service 
(QoS) support to improve the realism of the gaming session. As a result, although a 
community of online game players currently participate and play games over the 
Internet, their numbers have been limited. Since QoS is not guaranteed, the billing 
model for e-gaming service today is primitive and allows only free gaming or pay-in- 
advance. 

Online gaming is important to broadband emerging service providers 
(broadband ESP) today because it makes an Internet site "sticky." The metric by 
which Internet sites are valued today is not only the number of hits per day but also by 
the average amount of time a user spends at the site (stickiness). Online gaming 
provides content that not only increases the number of hits, but also makes a user 
linger at the site. Furthermore, the longer users stay at a site, the more targeted or 
untargeted advertisement can be shown to the users, which translates to more revenue 
opportunities. Online gaming also creates the feeling of an online conrmiunity that 
allows the broadband ESP to bundle other broadband premium services like video, 
streaming advertisements, music, etc. 
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SUMMARY OF THE INVENTION 

It may be seen from the foregoing that it is desirable to support advanced e- 
gaming services to provide scalability, QoS, and a mechanism for billing to overcome 
the problems associated with the central server. In particular, the present invention 
supports QoS provisioning, and avoids the bottleneck of routing gaming 
communications such as players' moves and other input through a game server. 

In accordance with an embodiment of the present invention, a method of 
setting up a multi-user communication session over a global computer network is 
provided. The method includes first sending a session participation request message 
from a first user to a second user, where the session participation request message 
includes the first user's QoS requirements for the session. The first user receives a 
negotiating message from the second user in response to the session participation 
request message, where the negotiation message includes the second user's QoS 
requirements for the session responsive to the first user's QoS requirements. The 
resource availability in access networks of the first and second users according to the 
second user's QoS requirements is determined, and resources in the respective access 
networks of the first and second users are then reserved in response to resources being 
available to achieve the second user's QoS requirements. 

The first user thereafter sends an acknowledgement message to the second user in 
response to receiving the negotiating message to indicate the completion of QoS 
provisioning. 

In accordance with another embodiment of the present invention, a method of 
setting up an e-gaming session played over a global computer network is provided. 
The first player sends a session participation request message to a second player via a 
first game server, where the session participation request message includes the first 
player's QoS requirements for the session. The first player receives a negotiating 
message from the second player via a second game server in response to the session 
participation request message, where the negotiation message includes the second 
player's QoS requirements for the session responsive to the first player's QoS 
requirements. The resource availability in the second player's access network is 
determined according to the second player's QoS requirements, and resources in the 
second player's access network are reserved in response to resources being available 
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to achieve the second player's QoS requirements. The negotiating message is then 
forwarded from the second game server to the first game server. The resource 
availabiHty in the first player's access network is determined according to the second 
player's QoS requirements and the resources in the first player's access network are 
reserved in response to resources being available to achieve the second user's QoS 
requirements. An acknowledgement message is then sent from the first player directly 
to the second player in response to receiving the negotiating message to indicate the 
completion of QoS provisioning. 

In accordance with yet another embodiment of the present invention, a multi- 
user communication system over a global computer network includes a first server 
onto which a first user is logged, a first policy server in communication with the first 
server, a second server onto which a second user is logged, and a second policy server 
in communication with the second server. The first user sends a session participation 
request message to the second user via the first and second servers, where the session 
participation request message includes the first user's QoS requirements for the 
session. The second user then send a negotiating message to the second server user in 
response to receiving the session participation request message, where the negotiation 
message includes the second user's QoS requirements for the session responsive to the 
first user's QoS requirements. The second policy server determines resource 
availability in the second player's access network according to the second user's QoS 
requirements and reserves resources in the second user's access network in response 
to resources being available to achieve the second user's QoS requirements. The 
negotiating message is then forwarded from the second server to the first server. The 
first policy server also determines resource availability in the first player's access 
network according to the second user's QoS requirements and reserves resources in 
the first player's access network in response to resources being available to achieve 
the second user's QoS requirements. The negotiating message is forwarded from the 
first server to the first user. The first user then sends an acknowledgement message 
directly to the second user in response to receiving the negotiating message to indicate 
the completion of QoS provisioning. 
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Other aspects and features of the present invention will become apparent to 
those ordinarily skilled in the art upon review of the following description of specific 
embodiments of the invention in conjunction with the accompanying figures. 



ATTORNEY DOO^T NO. 
12406RRUS02U 



6 



PA^Brr APPLICATION 



BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present invention, the objects and 
advantages thereof, reference is now made to the following descriptions taken in 
connection with the accompanying drawings in which: 
5 FIGURE 1 is a simplified flowchart of an e-game session according to the 

teachings of an embodiment of the present invention; 

FIGURE 2 is a simplified flowchart of an e-game login process according to 
the teachings of an embodiment of the present invention; 

FIGURE 3 is a message flow diagram of an e-game session initiation and 
10 resource reservation process according to the teachings of an embodiment of the 

present invention; and 

FIGURE 4 is a message flow diagram of a player joining an ongoing e-game 
session process according to the teachings of an embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE DRAWINGS 

The preferred embodiment of the present invention and its advantages are best 
understood by referring to FIGURES 1 through 4 of the drawings, like numerals being 
used for like and corresponding parts of the various drawings. 

FIGURE 1 is a simplified flowchart of an e-game session 10 according to the 
teachings of an embodiment of the present invention. The terms "e-game," "on-line 
game" and "web-based game" are used substantially synonymously herein to refer to 
a game session in which players' moves as well as the game text, graphics, audio, and 
video data are relayed over the Internet or a global computer network. At the 
beginning of an e-game session, the game session is initiated and setup at a game 
server local to a user. In the distributed e-gaming architecture of the present 
invention, each administrative domain is served by at least one local game server, and 
the game servers are operable to communicate with one another in a peer-to-peer 
fashion. The local game server sets up the e-game session, as shown in block 12, and 
also reserves resources needed to support the quality of service (QoS) required for the 
session, as shown in block 14. The local game server may obtain the user name and 
password, and authenticates the user's authorization to play. This may include 
verifying the user's subscription to game playing, if applicable, or verifying the user's 
payment methods. The session initiation is then completed in block 16, and game 
play proceeds in block 18. Usage records for the session are then generated to 
facilitate billing. Unlike conventional e-gaming sessions, the players play directly 
against or with each other without redirecting the gaming data through any game 
server. In block 20, the e-game session terminates, at which time the local game 
server may obtain the session usage records and post the records for billing. The 
session terminates in block 22. 

FIGURE 2 is a simplified flowchart of an e-game login process 30 according 
to the teachings of an embodiment of the present invention. A user first enters a URL 
(uniform resource locator) or Internet address of a game portal or web site and 
accesses the site stored at a local game server, as shown in block 32, The user then 
indicates a desire to play a game, as shown in block 34. Typically, the user may click 
on an icon, button, or a link which initiates a download of a game web page to the 
player's computer. The player may enter his or her user name, password or other 
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authenticating data so that the game server may verify that the player is a subscription 
user, or a registered user, as shown in block 36. Alternatively, the game portal may 
allow unregistered users to play selected games or try out a predetermined number of 
sessions without registration requirement or payment. In blocks 38 and 40, the local 
game server displays a list of games available to the player and the player selects a 
particular game. In response to the player's game selection, the game server displays 
a form or a series of questions designed to solicit the player's participation rules. The 
participation rules include the manner in which the player chooses to participate in the 
game (including, for example, player, strategist or spectator) and the capabilities of 
the player's computer. Thereafter, the game server displays a game window to the 
player, as shown in block 44, so that the player may begin to participate in the game, 
as shown in block 46. The user login process ends in block 48. 

Future e-gaming will be a multimedia session in which audio, video, data 
(chat), game control messages will be exchanged. The ability for a player to join an 
ongoing session is also desirable. Protocols such as SIP (Session Initiation Protocol), 
SAP (Session Announcement Protocol) and SDP (Session Description Protocol) 
provide these features. For example, an SIP INVITE with SDP is used before the e- 
gaming session begins for capability exchange which includes codes for audio and 
video UDP ports for voice, video and gaming control messages. SAP is used to 
announce an ongoing e-gaming session to new players. After the session initiation 
and capabilities exchange phase, the gaming server initiates the resource reservation 
phase for packet cable by using QoS. After the resource reservation phase, the 
players are created and game session setup messages are exchanged. 

FIGURE 3 is a message flow diagram of an e-game session initiation and 
resource reservation process according to an embodiment of the teachings of the 
present invention. A first player 50 (Player 1) sends a session participation request 
message 52 containing the name or identifier of a second player 62 (Player 2) to a 
local game server 54. Session participation request message 52 may include 
bandwidth requirements and the QoS requirements for the gaming session. For 
example, the QoS requirements may include end-to-end packet delay, maximum 
tolerable lag, etc. The session descriptor may also contain a description of the user's 
computer terminal capabilities, such as processing power, memory, modem speed, 
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etc. The session setup protocol can use an extended SIP and SDP message set. The 
SIP can be extended to support QoS for different classes of games. For example, a 
class of games (Class 1) may be characterized by turn-based real-time game playing, 
such as chess, checkers, and cards; a second class of games (Class 2) may be 
5 characterized by real-time interactive games that preferably have latency less than 50 

milliseconds, for example; a third class of games (Class 3) may be characterized by 
real-time action/simulation/role playing games where latency less than 50 
milliseconds is required for optimal game play. Still a fourth class (Class 4) may be 
characterized by low-demand spectator and strategists in a gaming session which is 
10 satisfied by best efforts using available bandwidth. 

The required QoS for a communication session may be directly correlated to 
the cost billed to the participant. The requested level of security may also be 
considered. The following table shows different billing types for e-gaming that can 
be accomplished with extended SDP contemplated by the present invention. 

15 



BILLING 


ID 


Pay as You Play (time-based) 


1 


Pay Per Session 


2 


Subscription 


3 


Free Based on a Conditional Criteria 


4 


Free 


5 



An example of an SLP INVITE with extended SDP message of the present 
invention to carry session information and billing information is shown below: 



20 C -> SI: INVITE sip:jerry@can.nortelnetworks.com SIP/2.0 

Via: SIP/2.0/UDP rich.us.nortelnetworks.com 
From: TOM <sip:tom@us.nortelnetworks.com> 
To: JERRY <sip:jerry@can.nortelnetworks.com> 
Call-ID: 2892326565@rich.us.nortelnetworks.com 

25 Cseq: 1 INVITE 

Subject: Lets Play Diablo game 
Content-Type: application/sdp 
Content-Length: . . . 



30 



V=0 

0=tom 2346442901 2346444901 IN IP4 47.177.57.140 
s=Online Game 
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I=A new e-Game called Diablo 
U=http ://www . games .com/di able .pdf 
C=IN IP4 games.rich.nortelnetworks.com 
T=23 12349034 2312623423 
*M=application 42012 udp gm 
*B=50 

*A=qos:mandatory sendrecv 3 
*A=security:mandatory sendrecv 
*A=billing:mandatory 1 

The C field may contain a unicast or multicast address. The fields marked with an 
are or include extensions according to the present invention. M is used to specify 
the game format (gm) type; B is used to specify the required bandwidth or the latency 
requirement of 50 milliseconds; A indicates the QoS requirement of game 
classification level 3 and the security requirements, the security requirements, and the 
billing classification. The standard SIP protocol is described in "SEP: Session 
Initiation Protocol", Request For Comments 2543. 

A game server 54 local to Player 1 then seeks out the game server for Player 2, 
one onto which Player 2 is logged in. Game server 54 searches its directory and 
proxies the message to that game server 58. If the second game server cannot be 
located, the INVITE message is forwarded to another server in the global computer 
network or Internet 57 which may be able to determine the address of the game server 
for Player 2. The following is an example of a message sent to Player 1 from game 
server 54 in response to the INVITE message. 



S1->C: SIP/2.0 180 Ringing 

Via: SIP/2.0/UDP rich.us.nortelnetworks.com 
From: TOM <sip:tom@us.nortelnetworks.com> 
To: JERRY <sip:jerry@can.nortelnetworks.com> 
Call-ID: 2892326565@rich.us.nortelnetworks.com 
Cseq: 1 INVITE 
Content Length: 0 

The INVITE message eventually reaches game server 58 and Player 2 (Paths 56 and 
60, respectively). Player 2 may modify the session descriptor to suit his or her needs. 
Player 2 then sends a negotiating message such as an SIP OK message with session 
QoS requirements (possibly modified) and his or her terminal capabilities to game 
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server 58 (path 64), which forwards the message to game server 54 for Player 1 (path 
66). 

Before forwarding the OK message, game server 58 for Player 2 
communicates the QoS requirement information to its policy server 67 (path 69), 
which invokes the QoS-enabling mechanism in the access network of Player 2. 

On receiving the negotiating message (OK message), game server 54 of Player 
1 communicates the QoS data to its policy server 70 (path 68). Policy server 70 
makes an admission control decision at this point for the session, based on the 
requested QoS and resource availability. If Players 1 and 2 are successfully admitted, 
policy server 70 then triggers the access resource reservation phase (not shown) at its 
access terminator system (ATS) 72. After the access resource reservation is 
successfully completed, the OK message is forwarded to Player 1 by game server 54 
(path 74). Player 1 then sends an "Acknowledgement" or ACK message directly to 
Player 2, as indicated by path 76. The ACK message can be routed directly without 
passing through the game servers because both players know each other's IP address 
through the "Session Participation Request" and the "Negotiating" messages. The 
receipt of the ACK message by Player 2 completes the capability negotiation and QoS 
provisioning phase session setup phase. The e-gaming session can now begin. ATS 
72 and 73 or access concentrators/routers 82 and 84 may start generating usage 
records for the gaming session to facilitate billing. 

In the present example, an assumption was made that resource reservation is 
required only in access. For cable, DOCSIS 1.1 resource allocation is invoked at a 
cable modem terminator system to support the QoS for various e-gaming sessions. 
The policy server also configures the routers in the access network to support the 
required QoS for the gaming session. If end-to-end resource reservation is needed, 
layer 3 reservation mechanisms such as Resource reservation Protocol, set forth in 
Request for Comments 2205, can be used. 

After the session setup phase, the exchange of actual gaming messages 
between players begins. Each move or input of a player is encapsulated in a message 
and sent to the opponent player(s). In the present invention, the gaming messages can 
be sent directly between players via the Internet without passing through one or more 
game servers. In conventional e-gaming sessions these messages are transported over 
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(UDP), an unreliable protocol and unsuitable for e-gaming. The player input and 
movement messages are not only time-critical, but also require lossless and reliable 
sequential delivery. A packet delivered out of order becomes meaningless. Lost 
packets may result in players' moves being lost. The game session is terminated by 
using the SIP BYE message sent by a user's computer to the local game server. This 
enables the termination of the session with respect to that particular player if more 
than two players are playing or the entire session if only two players are playing. 
Billing records are then generated for the terminating player(s). 

Protocols such as DOCSIS 1.1 support the simultaneous transmission of 
multiple traffic flows over the cable medium providing the negotiated QoS 
guarantees. In the downstream direction the DOCSIS MAC can schedule traffic 
directly to meet the negotiated QoS. Therefore, special scheduling is not required. 
The upstream channel is contention-based and various types of polled/request/grant 
schemes are used to control the resource assignment and hence, the QoS, over the 
upstream channel. DOCSIS LI allows negotiation of QoS parameters such as 
bandwidth, traffic priority, latency and jitter, DOCSIS 1.1 supports non-real-time 
polling, unsolicited grant, real-time polling and unsolicited grant with activity 
detection upstream scheduling services. 

In non-real-time polling, the ATS sends an unicast polling message 
(REQUEST OPPORTUNITY) to the cable modem, for example. If there is data to 
send, the cable modem sends a REQUEST message to the ATS and is replied by a 
GRANT message by the ATS if resource is available. This method is suitable for 
non-real-time, bursty data applications such as web browsing and file transport 
protocol (FTP). 

In unsolicited grant, periodic grants are sent by the ATS to the cable modem at 
fixed intervals. This is suitable for constant bit rate traffic like PCM-encoded voice. 
Strict jitter control is provided. 

In real-time polling, ATS always provides periodic unicast polls. Thus any 
flow is guaranteed to receive periodic REQUEST OPPORTUNITY. This is suitable 
for bursty video or VoIP with silence suppression. 

In unsolicited grant with activity detection, ATS provides unsolicited grant 
when the flow is activated and provides periodic unicast polls when the flow is 
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inactive. This is suitable for VoIP traffic with comfort noise generation. Activity 
detection by the cable modem is required. 

The data traffic generated by a player during e-gaming can be quite 
unpredictable and bursty. However, once a message is generated, it needs to be 
delivered to the other player(s) within the shortest possible time. If unsolicited grant 
is used with a proper selection of the rate of the grants, optimal access is guaranteed. 
However, since the message generation can be quite random, much grants and thus 
resources can be wasted. If the data generated by each move of the player is fixed, 
the optimal resource usage with guaranteed access delay to a certain degree can be 
achieved by using the real-time polling scheduling algorithm. 

Referring to FIGURE 4, a message flow diagram showing the process for a 
player to join an ongoing e-game session is shown. As described above, SAP may be 
used to multicast gaming information, which also includes the QoS, security and 
billing information associated with the gaming session. Sessions are described using 
SDP. SAP announcer periodically multicasts packets containing the description of the 
session to a well-known multicast EP address and port. When a player initiates a 
communication or e-game session, the session information is registered with the local 
SAP server. A new player can listen to the well known IP address or port to receive 
the SAP message containing the session information. For example, the SAP message 
may contain the session title, QoS class and billing information, multicast address, BP 
address of the game host, etc. The following shows the SAP message header with 
extended SDP according to the present invention. 

_0 8 16 32 



V=l ART 



E I C I Auth Length | Msg ID hash 



Originating Source. . . 



Optional Authentication Data... 



Optional Payload Type. . . Application/SDP* 
Extended SDP* 



The fields marked with an indicates information added according to an 

embodiment of the present invention. 

Referring to FIGURE 4, a new player 90 desires to join an ongoing e-game 
session 92 involving multiple players 94-96, who are respectively associated with 
local game servers 98-100. Player 90 sends a session participation request message 
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such as an SIP INVITE message to 104 to his/her local game server 102. The session 
participation request message includes an ALSO header which contains the multicast 
address of the game session that the new player wants to join as well as the QoS 
requirements of the new player. Further, the flag field of the Call-Disposition 
argument of the INVITE message is set to "REACH FIRST, " which indicates that 
only one current player needs to acknowledge the receipt of the INVITE message. 
Local game server 102 then multicasts 106 the SIP INVITE to all participants 94-96 
of the game. The INVITE message reaches all the players current in the game, and at 
least one of the players replies with a 200-class OK message 108. If local game 
server 102 does not support multicasting, it may return a 600-class response to player 
90. Player 90 then sends an INVITE message with an ALSO field containing the 
address of the host player obtained from the SAP/SDP message. The OK message 
may include a QoS requirement for the communication session. On receiving the OK 
message, local game server 102 communicates the QoS information of player 90 to a 
policy server 112. Policy server 112 makes an admission control decision at this 
point for the session, based on the requested QoS and resource availability in the 
access network. If resources can be allocated according to the QoS requirements, 
then the OK message 114 is forwarded to player 90. On receiving the OK message, 
player 90 or his/her computer sends an ACK message 116 to local game server 102. 
Local game server 102 then multicasts the ACK message 118 to all current game 
participants. The game host server (not shown) adds player 90 to the current state of 
the game, and player 90 is allowed to join in the ongoing game. All the current 
players and the new player then continue in the gaming session using multicast 
messages without any server involvement. The game session may be terminated 
using a SIP BYE message, which is sent via the local game servers. 

Although the present invention has been described primarily in connection 
with e-gaming, it is equally applicable to a multi-user communication session where 
interactivity is desired. For example, the present invention may be used to implement 
a multimedia conference session between multiple users. 

While the invention has been particularly shown and described by the 
foregoing detailed description, it will be understood by those skilled in the art that 
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various changes, alterations, modifications, mutations and derivations in form and 
detail may be made without departing from the spirit and scope of the invention. 



